[00:40.340 --> 00:46.200]  Hi there! Welcome everyone. We're here with Dylan and Allison, who presented here at DEF CON
[00:46.200 --> 00:51.640]  SAFEMODE on lateral movement and privilege escalation in GCP. Compromise any organization
[00:51.640 --> 00:57.100]  without dropping an implant. And I have to say, one of the highest theatrical production values
[00:57.100 --> 01:02.240]  I think I've seen so far in a video, including the hacker with the hoodie doing the whole, you know,
[01:02.240 --> 01:07.940]  hey, let's just pound on things, but with a real hacker. So, it was pretty entertaining to say
[01:07.940 --> 01:14.360]  the least. So, welcome both of you to DEF CON here at SAFEMODE. Thank you. It's great to be here.
[01:14.720 --> 01:21.000]  Thank you. Yeah, so first thing I want to kind of ask, just to get things started, so really,
[01:21.000 --> 01:26.060]  right, you like, has anything changed since the DEF CON, since you recorded your DEF CON talk
[01:26.060 --> 01:31.160]  and it was published? Any major changes or anything you want to share with the DEF CON community?
[01:32.140 --> 01:37.560]  Yeah, so there are actually a number of changes that Google's been rolling out,
[01:38.420 --> 01:43.800]  all of which have been super positive. Oh, it looks like Allison's video cut out.
[01:44.360 --> 01:52.880]  I guess she'll rejoin. I'll be answering the question though. So, I guess most notably,
[01:52.880 --> 01:59.480]  the service accounts or the roles and permissions which can make use of the default service account
[01:59.480 --> 02:07.340]  without ACT-AS are being end of life in 2021. And that was the direct response to this talk.
[02:07.520 --> 02:13.540]  And what that means is you will need the ACT-AS permission in addition to the other permission
[02:13.540 --> 02:18.340]  in order to do the action of attaching a service account to those services,
[02:18.340 --> 02:22.980]  even for the default service account. So, that's going to change things a little bit.
[02:22.980 --> 02:28.180]  In terms of what the overall security story is, I'm not 100% sure because it will lead to the
[02:28.180 --> 02:34.980]  proliferation of the ACT-AS permission. Ideally, folks will be applying that at the resource level
[02:34.980 --> 02:40.280]  for least privileged scope service accounts. But like we showed in the talk, people often apply it
[02:40.280 --> 02:45.740]  at the project level. So, it sort of opens the opportunity up for you to make yourself more
[02:45.740 --> 02:52.160]  secure, but it also kind of opens up more foot shooting opportunities. Another interesting change
[02:53.100 --> 03:01.420]  was that the very quick clip that I cut over to GitHub for and showed a bunch of people
[03:01.420 --> 03:06.500]  uploading their GCP service account credentials, I noticed that when I ran the same search on GitHub,
[03:06.500 --> 03:13.180]  those keys are no longer there. I assume someone went through a lot of effort to get those removed.
[03:13.180 --> 03:18.160]  And I was just thinking in the back of my mind, you know, they can go through that effort,
[03:18.160 --> 03:25.060]  they're still in that Arctic vault. So, those keys are immortalized in some capacity.
[03:25.460 --> 03:30.120]  But it's good that they took them down. It makes it more tricky to just immediately exploit
[03:30.120 --> 03:33.240]  lots of people at the gate from the talk. And I'm glad they did that.
[03:34.680 --> 03:40.280]  Awesome. Awesome. Yeah. So, kind of another kind of thought provoker. So, as I watch your video,
[03:40.280 --> 03:44.660]  I liked kind of at the beginning how you're like, here's how AWS identity access management works,
[03:44.660 --> 03:49.200]  right? And kind of here's the GCP model. You know, based on your experience so far,
[03:49.200 --> 03:53.480]  like, I guess, do you think one is better? Right? Do you prefer one model of the other?
[03:53.480 --> 03:56.020]  Do you think they both have their place? Kind of what's your take on that?
[03:57.620 --> 04:04.280]  That's a good question. There are definitely elements of the GCP platform that are unique
[04:04.280 --> 04:11.180]  and nice to use that AWS doesn't have. But in terms of the IAM story, I would say,
[04:11.180 --> 04:15.660]  generally speaking, from what I've observed, AWS more follows the principle of least privilege
[04:15.660 --> 04:21.460]  than GCP. And in that context, I guess it depends on your perspective. If you're a brand new
[04:21.460 --> 04:25.760]  developer and you want to move really quick and you want to have everything open by default,
[04:27.080 --> 04:31.040]  GCP is an interesting choice. If you're a security engineer and you want to follow
[04:31.040 --> 04:36.640]  least privilege and lock things down, AWS, from my observations, tends to do that more.
[04:37.540 --> 04:40.840]  So, actually, there's a question in the chat that kind of goes into that. So,
[04:40.840 --> 04:48.360]  go ahead and ask it. It was, for those of us with existing and sprawling GCP environments,
[04:48.360 --> 04:52.980]  given that the org policies aren't retroactive, what are some good approaches for tackling
[04:52.980 --> 04:59.980]  remediation for those deployments? That's a really good question. And
[05:00.700 --> 05:05.700]  I think we wanted to go into a little bit more depth into that subject in the video, but we
[05:05.700 --> 05:12.800]  didn't have the time to really dig into it. Remediation is really tricky. So, you can enable
[05:12.800 --> 05:17.540]  org policy when you're first starting an organization or later. And for all new things
[05:17.540 --> 05:21.700]  going forward, they'll get the benefits of it. But for all the existing projects that are already
[05:21.700 --> 05:29.400]  using the default service account, it's really hard to wean yourself off of it for a couple of
[05:29.400 --> 05:36.060]  reasons. First is that if you switch service counts on a live VM, which a lot of services
[05:36.060 --> 05:41.100]  are powered by, that VM needs to actually be stopped and started again to get the new service
[05:41.100 --> 05:49.360]  account. The second is that the default service account is kind of, like, it's not just, like,
[05:49.480 --> 05:54.220]  a set of permissions that's applied to your services, but it's also an IAM policy that's
[05:54.220 --> 05:59.760]  shared across all of your services. And so, you have two different services using the same policy.
[05:59.760 --> 06:04.000]  If you want to make modifications to that policy, it's going to affect both services. So, that makes
[06:04.000 --> 06:08.720]  it a little bit tricky. And then the way service accounts work is you can both use them as keys
[06:08.720 --> 06:12.540]  and you can use them as attached identities, similar to AWS. And so, you have to kind of
[06:12.540 --> 06:20.660]  enumerate all the different use cases and kind of systematically knock them out one at a time.
[06:20.660 --> 06:24.320]  So, you have to see how many keys are exported, you have to see is it attached to any instances,
[06:24.320 --> 06:27.080]  you have to check the stack driver logs to see whether or not they're in use.
[06:28.480 --> 06:35.380]  All of that can be really tricky, but some tools that do help with that are the Asset Analyzer API
[06:35.380 --> 06:42.820]  to see where the default service accounts are in use. And then the other one that's handy is the
[06:42.820 --> 06:50.500]  role recommender. So, you can get some idea of, based on the last 90-day look back period
[06:50.500 --> 06:55.820]  for a given project, how many permissions has the default service account actually used.
[06:56.280 --> 07:01.840]  Now, that's not the whole story for a number of reasons, one of which is the role recommender
[07:01.840 --> 07:07.160]  will only apply those recommendations sort of, you know, if the role binding is at the project
[07:07.160 --> 07:10.500]  level, it'll make the recommendation at the project level, it won't make the recommendation down
[07:11.140 --> 07:16.480]  at the resource level, and it also won't recommend that you split your IAM into two different,
[07:16.480 --> 07:21.860]  you know, identities, if maybe multiple services are using the default service account, it'll make
[07:22.120 --> 07:26.700]  a recommendation based on the summation of all those services, it won't say this service should
[07:26.700 --> 07:31.440]  have this scope of permissions and that service should have that scope of permissions. But it
[07:31.440 --> 07:37.500]  does kind of go a long way in terms of very quick remediation that you can do for looking backward
[07:38.000 --> 07:40.540]  for the things that work policy can't cover.
[07:42.720 --> 07:48.280]  Gotcha. Cool. Yeah, so I kind of had a thought too. So as I was watching this, I was like,
[07:48.280 --> 07:52.240]  man, this seems like a cool way for, you know, an attacker to maybe gain persistence in one of
[07:52.240 --> 07:55.920]  these, you know, GCP environments, like, you know, setting up an account, and, you know,
[07:55.920 --> 07:59.580]  maybe before some of these changes, like, hey, could you set up an account, give it privileges,
[07:59.580 --> 08:03.780]  and then does it just fly under the hood? I guess, what's your thought around that? Like,
[08:03.780 --> 08:06.680]  could you see that as a potential attack vector? Or would you see maybe other
[08:06.680 --> 08:11.290]  kind of attack vectors for hiding in the IAM noise of GCP?
[08:12.080 --> 08:17.520]  Yeah, I mean, I think a lot of what we showed is that this lateral movement,
[08:17.520 --> 08:24.920]  privilege escalation, persistence, it can all be done without dropping implants on a server.
[08:25.200 --> 08:30.800]  Like, you might for act as want to spin some things up, introduce them into the environment.
[08:30.800 --> 08:37.140]  For servers that have maybe endpoint software, monitoring malware and things like that,
[08:37.760 --> 08:42.360]  it wouldn't set those things off. So, I think it is good for persistence in that way. We'll
[08:42.360 --> 08:47.300]  probably need new tooling to look for these types of attacks. One of the services that Google offers
[08:47.300 --> 08:55.160]  to kind of help with this is the... I forget exactly what it's called, but it's a service
[08:55.160 --> 09:01.060]  that will monitor your Stackdriver logs and look for bad things and then alert you if it sees bad
[09:01.060 --> 09:10.640]  things. And so, it's watching those cloud APIs, which will be auditable. And examples of things
[09:10.640 --> 09:18.100]  they've used in the past are like known bad IP addresses for like crypto miners. If they ever
[09:18.100 --> 09:21.160]  show up in your Stackdriver logs, they'll send you an alert. But I expect these types of cloud
[09:21.160 --> 09:29.180]  attacks will become more and more a piece of that story. We also briefly showed a lot fishing.
[09:29.180 --> 09:34.520]  I think that's also a great way for persistence because if you get somebody to click an allow
[09:34.520 --> 09:41.160]  link on wide scope open permissions, you can get the permissions of the user without having to get
[09:41.360 --> 09:47.100]  a service account credential and it functions the same way. So, that's another way that you can
[09:47.100 --> 09:50.080]  sort of use these same techniques and get persistence.
[09:50.880 --> 09:55.120]  Something to note on this too is service account keys. So, if someone is able to create a service
[09:55.120 --> 09:59.440]  account and give it access to a resource or something, a project, that the service account
[09:59.440 --> 10:06.220]  keys last for 10 years. So, if they're never rotated by the organization or deleted, then
[10:06.220 --> 10:15.120]  you have that key for a very long time. Wow. Yeah, that's definitely interesting.
[10:15.560 --> 10:23.120]  Oh, another quick note on that. The long-lived exported credentials last for 10 years,
[10:23.120 --> 10:30.020]  like Alice mentioned, which is interesting. The short-lived instance credentials, those last,
[10:30.020 --> 10:34.740]  I think, closer to 10 minutes, but that'll persist after an instance is terminated. So,
[10:34.740 --> 10:39.220]  if you're an attacker and you're exploiting something like an SSRF or even remote code
[10:39.220 --> 10:45.500]  execution, grab instance credentials, even after the defensive person deletes the instance,
[10:45.500 --> 10:48.120]  the attacker can still persist another 10 minutes.
[10:51.120 --> 10:56.400]  Okay. So, we had another question pop up here in chat and kind of along with your follow-up to
[10:56.400 --> 11:02.620]  what you're explaining. It says, what about abandoned service accounts? Say they're deleted.
[11:02.620 --> 11:07.480]  Do you end up with abandoned ACLs that exist on the resources and projects?
[11:09.520 --> 11:13.320]  That's a good question. Allison, did you want to take that?
[11:13.560 --> 11:20.380]  So, there's actually something that is kind of interesting about this where we've run into some
[11:20.380 --> 11:28.320]  bugs, actually, where a service account has been deleted and their IAM bindings were also removed.
[11:28.320 --> 11:33.340]  So, if a service account is deleted, the IAM binding can still exist there. So, maybe also
[11:33.340 --> 11:38.860]  if you have a user in your org and you remove them from G Suite, that IAM binding will still exist
[11:38.860 --> 11:46.200]  in your GCP projects with user at gmail.com or whatever that is. But there's also interesting
[11:46.200 --> 11:51.440]  things that can happen due to the undelete capabilities for service accounts, or if you
[11:51.440 --> 11:58.000]  delete a service account, IAM binding, like you asked, it still exists where that IAM binding was
[11:58.000 --> 12:03.380]  made. And if you do, if you try to undelete your service account, you're like, oh, maybe I actually
[12:03.380 --> 12:09.880]  need that. And you had, or you try to create a new service account with that same name,
[12:10.400 --> 12:16.100]  the IAM binding will reference the UID of the service account that was, that was deleted.
[12:16.100 --> 12:21.120]  So, you can have this weird like caching thing happen where you'll get like permission denied
[12:21.120 --> 12:26.940]  errors if you're using this. So, if I create service account A and I give it an IAM binding
[12:26.940 --> 12:33.160]  at my project and I delete it, then I recreate a new service account, service count A, that tries
[12:33.160 --> 12:38.800]  to reference that existing IAM policy, it doesn't work because it's referencing the old service
[12:38.800 --> 12:42.700]  account that was deleted by its unique ID. So, yeah, they exist and this can bring up some really
[12:42.700 --> 12:47.300]  weird bugs if you're trying to create new service accounts with the same name or undelete your
[12:47.300 --> 12:57.360]  service accounts and you're not updating the IAM policies in parallel. Cool. Yeah, so we kind of
[12:57.360 --> 13:00.760]  talked about this a little bit and you mentioned this in your talk too, kind of from the defender
[13:00.760 --> 13:06.880]  perspective, right? Like, there's rolled out like the IAM analyzer, there's the recommender,
[13:06.880 --> 13:11.400]  you know, I guess, what are, are there any other things or advice you'd give to blue teams looking
[13:11.400 --> 13:16.740]  to secure kind of the GCP environment, right? Or the IAM offerings, like detection opportunities,
[13:16.740 --> 13:20.740]  like the tool you mentioned, log analysis, like, are there any, any good things to try to
[13:20.740 --> 13:25.940]  really dive in? Like, hey, ingest this log feed and, you know, hey, we'll see all your IAM
[13:25.940 --> 13:33.600]  transactions or anything like that, any advice you give? That's a good question. A lot of
[13:34.660 --> 13:40.200]  people will recommend that you can pipe your Stackdriver logs over to BigQuery,
[13:40.540 --> 13:45.620]  so that you get a structured query language that's a little bit easier to work with than
[13:45.620 --> 13:53.340]  the filters in Stackdriver, easier to write detection rules for and such. I think that
[13:55.680 --> 14:03.840]  definitely the security API that exists at the org level has some very interesting
[14:03.840 --> 14:08.140]  introspections that you can do across your whole fleet, and they provide some suggestions and
[14:08.140 --> 14:14.320]  recommendations around other types of least privilege, like buckets that were left open to
[14:14.320 --> 14:18.880]  the internet and things like that. There's also a lot of other org policies that we didn't cover
[14:19.520 --> 14:24.100]  that also will improve your security story, but just aren't necessarily related to the content
[14:24.100 --> 14:33.400]  we talked about, like allowing your developers to add users outside of your organization
[14:33.980 --> 14:38.520]  to roles inside your organization. By default, that's allowed, so you can add a random Gmail
[14:38.520 --> 14:44.900]  account to a project. You can disable that via org policy. So it's definitely worth checking out
[14:44.900 --> 14:53.640]  those high-level org policies as well. And I think that we mentioned this as well in the talk,
[14:53.640 --> 15:01.200]  but we had general positive experiences providing feedback to Google, and in some cases,
[15:01.200 --> 15:07.140]  they actually put us in touch with PMs where we could explain these issues directly to them. And
[15:07.140 --> 15:13.280]  so in that regard, we strongly recommend people to engage with Google around pain points and
[15:13.280 --> 15:17.900]  tell them what an ideal workflow would look like. And in our case, they were receptive and worked
[15:17.900 --> 15:22.460]  with us on those things. Yeah, I was actually going to dive a little into that too. So again,
[15:22.460 --> 15:26.920]  working with Google that closely, again, it's always an interesting thing when you're
[15:26.920 --> 15:32.540]  approaching someone with base-level issues like that, how do they respond? Do you have any other
[15:32.540 --> 15:37.460]  tips for folks who'd be in similar situations, like reaching out to a Google or another company,
[15:37.460 --> 15:42.620]  like anything you learned out of that that you'd do better next time? Well, I think what was
[15:42.620 --> 15:48.200]  interesting is there's kind of two ways to engage with Google. There's the customer way,
[15:48.200 --> 15:54.100]  and then there's the vulnerability way. So you can submit to their bug bounty, and they get a very
[15:54.100 --> 15:58.160]  binary, this is a problem, this isn't a problem, right? If it's a problem, they'll pay you and
[15:58.160 --> 16:01.700]  they'll fix it. If it's not a problem, they'll close the ticket, and that's the end of the story.
[16:02.200 --> 16:07.440]  That's the bug bounty way. And you're interacting with the security engineer when you do that
[16:07.440 --> 16:14.220]  on the other end of that ticket. When you go the customer route, you're talking with a PM around
[16:14.220 --> 16:20.040]  them building products and giving them feedback about existing products. And that's a continuous
[16:20.040 --> 16:29.160]  story that doesn't end, and it's not binary. You have to sort of go through in-depth how security
[16:29.160 --> 16:33.100]  problems manifest themselves and things like that, which you might not have to do if you're talking
[16:33.100 --> 16:40.160]  to a security engineer. And you get to continue that conversation indefinitely. It's not a binary,
[16:40.160 --> 16:44.760]  you know, this is a problem, this isn't a problem, okay, ticket closed. So we pursued both of those
[16:44.760 --> 16:58.420]  paths concurrently. And I think that probably depends on your particular use case. But there
[16:58.420 --> 17:03.900]  were some things which we submitted as bugs through the bug bounty, and we thought that they
[17:03.900 --> 17:09.080]  would just be recognized as bugs and fixed. But they were actually just closed out as working
[17:09.080 --> 17:14.400]  as intended. And for those things, going the customer route actually proved to be more effective.
[17:16.320 --> 17:21.620]  Cool. That's great advice. Great advice for other people. I guess the other question I have, too,
[17:21.620 --> 17:26.120]  so it's kind of what's next, right? You kind of really, I guess, gone into a lot of the problems
[17:26.120 --> 17:31.840]  you've done a lot of improvement on this front with Google. What's your next for the research
[17:31.840 --> 17:35.620]  front? Are you going to continue to refine more attacks here, looking at other things,
[17:35.620 --> 17:43.260]  kind of what's next for the both of you? So recently, I did notice someone sent me some
[17:43.260 --> 17:51.180]  good resources that Rhino Security wrote up on some other GCP privilege escalation techniques,
[17:51.180 --> 17:59.400]  and they released some proof of concept tools. I think it would be cool if sort of the community
[18:00.920 --> 18:05.760]  helped bundle all of those tools into one framework. Of course, I'm selfishly hoping
[18:05.760 --> 18:12.600]  that's gsploit, so that we can kind of have like a metasploit for cloud. So I thought that, you
[18:12.600 --> 18:19.220]  know, that might be fun to consolidate some of that stuff. But beyond that, I don't have a lot
[18:19.220 --> 18:24.180]  of plans to do more extensive work in GCP. What about you, Allison?
[18:25.180 --> 18:31.980]  Yeah, for public research wise, I don't think I'll be elaborating on this topic for a while.
[18:31.980 --> 18:35.920]  But definitely something that I'm personally interested in learning more about and seeing
[18:35.920 --> 18:42.780]  the state of how different cloud providers, Google and AWS tackle IAM, because it's something that's
[18:42.780 --> 18:49.120]  really difficult, and I think is going to be changing very frequently for a long time,
[18:49.120 --> 18:55.100]  because it's such a hard problem to try to tackle. So no public research for the near future,
[18:55.100 --> 18:57.240]  but definitely interested in seeing what happens.
[18:59.160 --> 19:03.500]  And I have a question that kind of came up when I was watching your talk as well.
[19:03.520 --> 19:10.560]  Kind of going back to the tooling, you mentioned that you all developed a framework, gsploit. Is
[19:10.560 --> 19:14.380]  that something that has been or you plan on releasing anytime in the future?
[19:14.800 --> 19:19.820]  So yeah, it's already live. We linked to it in the talk. And you can check it out. It's
[19:19.820 --> 19:24.380]  on GitHub and Docker Hub. So it's just a little Docker container you can run.
[19:24.680 --> 19:30.100]  It was definitely released more on the proof of concept side than production code side. So
[19:30.100 --> 19:36.460]  some people found some bugs in it already and I'm expecting more. But it does the things that
[19:37.000 --> 19:42.860]  we videoed. So those demos, we can reproduce them with the tool.
[19:43.520 --> 19:47.400]  Cool. And then it looks like we have one more question in the chat.
[19:47.760 --> 19:53.200]  From your talk, I got the idea that in AWS, the account holder owns the permissions. But
[19:53.200 --> 19:58.240]  doesn't that cause a problem for research owners who need or want to provide permissions when the
[19:58.240 --> 20:04.360]  account is not under their control? I think this kind of gets at the heart of
[20:04.360 --> 20:11.920]  what we opened the talk with, which is whether or not your IAM model is resource-centric or
[20:13.140 --> 20:19.800]  user-centric. So is it basically the resource owner that controls who can access the resource?
[20:19.800 --> 20:25.100]  Or is it the identity owner that controls what resources that identity can access?
[20:25.100 --> 20:29.560]  And I think that's sort of the main difference between the two IAM stories
[20:30.840 --> 20:36.840]  in AWS versus GCP, at least that we opened with. We talked about some of the challenges that come
[20:36.840 --> 20:43.540]  up with the resource-centric model that's in GCP. We didn't really touch on the challenges
[20:43.540 --> 20:52.480]  of the inverse of that in AWS. And to be honest, I'm not an expert in AWS IAM by any means.
[20:52.480 --> 20:55.800]  And so I'd be curious to know if someone else wanted to do a deep dive on
[20:55.800 --> 20:59.540]  what those cons are.
[21:01.980 --> 21:08.300]  It also depends on how you're managing your infrastructure. It depends on are you
[21:08.300 --> 21:12.160]  allowing engineers to manage different infrastructure configurations, or do you
[21:12.160 --> 21:17.380]  have kind of a more centralized way that you're provisioning access within an account, too?
[21:17.380 --> 21:18.920]  Something to think about.
[21:21.020 --> 21:25.780]  Cool. Yeah, and I guess one thing I didn't really ask there, I don't remember, is why GCP?
[21:25.800 --> 21:31.580]  What kind of drew you to this area for research? Why did you look at this and the weaknesses here?
[21:32.840 --> 21:41.480]  Well, I think some of the defaults were definitely a little eye-opening. I guess
[21:41.480 --> 21:50.380]  the full story of this is someone briefly compressed down in the back of an Uber ride
[21:50.380 --> 21:56.860]  on my way home. I was sharing a car with someone. A bunch of crazy things in GCP that I found hard
[21:56.860 --> 22:03.580]  to believe. Yeah, all these things run as almost full administrator by default. And
[22:05.060 --> 22:11.440]  those things kind of prompted me to poke into it a little more. And then I think my poking
[22:11.440 --> 22:16.520]  got Allison poking, and then we just followed the rabbit hole as far as it would go.
[22:18.640 --> 22:23.320]  Cool. Yeah, there is one other question here that just came in the chat, too. And I don't
[22:23.320 --> 22:27.800]  know if you know the answer, but which model does Azure take? Is it more resource or identity-centric?
[22:29.320 --> 22:35.500]  Actually, not sure. I'm not familiar with Azure very much. I also wouldn't be able to speak to
[22:35.500 --> 22:41.240]  Oracle Cloud, IBM Cloud, or Alibaba Cloud, but I'm very curious to know the case for all of us.
[22:42.240 --> 22:44.700]  Future research for others to look into.
[22:45.780 --> 22:46.740]  Yeah, definitely.
[22:47.360 --> 22:53.040]  Awesome. Yeah, so we're getting near the end of our time here. But really, a couple last final
[22:53.040 --> 22:58.160]  ups. First, what should people look into if they're interested in learning more about the GCP
[22:58.700 --> 23:01.620]  identity access model? Where would you recommend someone start
[23:01.620 --> 23:06.960]  if they're trying to figure out how does this work, and maybe if they want to dive in themselves?
[23:08.380 --> 23:14.300]  Yeah, there's actually... the documentation, I think, is really great to start with. Really,
[23:14.300 --> 23:19.080]  just read it in its entirety. It's a lot of information. But from a hardening perspective,
[23:19.080 --> 23:26.360]  Google also recently released a new blog post that outlines some of the... in one place,
[23:26.360 --> 23:31.280]  not in each individual services, IM docs, some of the different steps you can take to
[23:31.280 --> 23:35.120]  harden the IM of the different services that we brought up in our talk.
[23:35.720 --> 23:42.360]  Oh, yeah. And on that subject, that blog post is also an answer to earlier questions of what
[23:42.360 --> 23:46.920]  they've done since the talk. That blog post was done in response to the talk.
[23:48.840 --> 23:55.140]  Awesome. Yeah, so someone said GCP is like gone cloud pwning, which seems pretty apt.
[23:56.700 --> 24:01.240]  But yeah, so really, I kind of opened up the last user. Anything else you really want to
[24:01.240 --> 24:06.660]  share with anyone? Any other last thoughts? Things that you think folks really should know
[24:07.320 --> 24:09.900]  about GCP before we move on?
[24:12.750 --> 24:20.410]  Oh, I'll just share that I am completely new to Twitter. I made a Twitter account last week,
[24:20.410 --> 24:27.010]  and I shared the handle in the video. But if folks want to connect with me there,
[24:27.010 --> 24:31.210]  and make me feel less lonely, because I don't have a lot of followers, feel free.
[24:32.150 --> 24:33.850]  What Twitter account is that?
[24:34.490 --> 24:40.970]  Oh, it's Insecure Nature. And it's linked in the talk. And I can also link in the chat.
[24:43.390 --> 24:47.610]  Okay, I guess my final thought would be don't trust the documentation. I know I said just read
[24:47.610 --> 24:52.090]  the documentation, but don't trust the documentation. When you're going and assessing
[24:52.090 --> 24:57.130]  things or building things, take kind of like a reverse engineering approach to analyzing things
[24:57.130 --> 25:03.210]  in the cloud. So test and verify the behaviors. Don't maybe just take what's in the documentation
[25:03.210 --> 25:07.670]  or what you think it would work, how you think something should work as the truth.
[25:08.310 --> 25:12.630]  Oh, yeah. And there are also a couple more privilege escalations, like I mentioned,
[25:12.630 --> 25:17.850]  that we just didn't have time to go into. We covered most of the ones that compromise
[25:19.990 --> 25:23.550]  a large set of identities. But there are privilege escalations for getting access
[25:23.550 --> 25:29.410]  to storage and those types of things. They're covered both in our earlier talk that we gave
[25:29.410 --> 25:35.070]  at BSides that I recommend folks check out. And like I mentioned, Rhino Security has done
[25:35.070 --> 25:43.120]  some pretty good write-ups recently on it. Awesome. Well, thank you both, Dylan and Allison.
[25:43.340 --> 25:47.540]  Really what I'd suggest too, if you have any particular links or summarized list of links
[25:47.540 --> 25:51.560]  you want to throw into the Discord chat room, that'll be helpful for everyone. There's lots
[25:51.560 --> 25:57.260]  of folks in there thanking you for the talk. So definitely well received by everyone here.
[25:58.180 --> 26:03.100]  But yeah, just want to say thank you again. Thank you for joining us for the DEF CON Safe Mode talk.
[26:03.100 --> 26:07.600]  Thanks for presenting in these weird times and hopefully see you in the future out in Vegas
[26:07.600 --> 26:12.720]  when we return. Sounds good. Thanks so much for having us. Thank you so much.
[26:12.720 --> 26:17.580]  Yeah, thank you. It's a pleasure. Take care. Yeah, thanks.
